漏斗|放入_海量请求下的接口并发解决方案

篇首语：本文由编程笔记#小编为大家整理，主要介绍了海量请求下的接口并发解决方案相关的知识，希望对你有一定的参考价值。

点击关注公众号&＃xff0c;实用技术文章及时了解

设定一个场景&＃xff0c;假如一个商品接口在某段时间突然上升&＃xff0c;会怎么办&＃xff1f;

生活中的例子来说&＃xff0c;假设冰墩墩在当天晚上上热搜之后&＃xff0c;迅速有十几万人去淘宝下单购买&＃xff0c;此时并没有做好对该商品的缓存预热以及准备&＃xff0c;如何操作&＃xff1f;

对于这个问题&＃xff0c;在电商高并发系统中&＃xff0c;对接口的保护一般采用&＃xff1a;缓存、限流、降级 来操作。

假设该接口已经接受过风控的处理&＃xff0c;过滤掉一半的机器人脚本请求&＃xff0c;剩下都是人为的下单请求。

服务限流

限流 主要的目的是通过对并发访问/请求进行限速&＃xff0c;或者对一个时间窗口内的请求进行限速&＃xff0c;一旦达到限制速率则可以拒绝服务、排队或等待、降级等处理。

限流算法

1. 漏斗算法

漏桶算法 是当请求到达时直接放入漏桶&＃xff0c;如果当前容量已达到上限&＃xff08;限流值&＃xff09;&＃xff0c;则进行丢弃或其他策略&＃xff08;触发限流策略&＃xff09;。漏桶以固定的速率&＃xff08;根据服务吞吐量&＃xff09;进行释放访问请求&＃xff08;即请求通过&＃xff09;&＃xff0c;直到漏桶为空。

漏斗算法的思想就是&＃xff0c;不管你来多少请求&＃xff0c;我的接口消费速度一定是小于等于流出速率的阈值的。

可以基于消息队列来实现。

2. 令牌桶算法

令牌桶算法 是程序以v&＃xff08;v &＃61; 时间周期 / 限流值&＃xff09;的速度向令牌桶中增加令牌&＃xff0c;直到令牌桶满&＃xff0c;请求到达时向令牌桶请求令牌&＃xff0c;如果获取成功则通过请求&＃xff0c;如果获取失败触发限流策略。

令牌桶算法和漏斗算法的思想差别在于&＃xff0c;前者可以允许突发请求的发生。

3. 滑窗算法

滑窗算法 是将一个时间周期分为N个小周期&＃xff0c;分别记录每个小周期内访问次数&＃xff0c;并且根据时间滑动删除过期的小周期。

如下图所示&＃xff0c;假设时间周期为1分钟&＃xff0c;将1分钟再分为2个小周期&＃xff0c;统计每个小周期的访问数量&＃xff0c;则可以看到&＃xff0c;第一个时间周期内&＃xff0c;访问数量为75&＃xff0c;第二个时间周期内&＃xff0c;访问数量为100&＃xff0c;如果一个时间周期内所有的小周期总和超过100的话&＃xff0c;则会触发限流策略。

Sentinel的实现 和 TCP滑窗。

接入层限流

nginx限流

Nginx 限流采用的是漏桶算法。

它可以根据客户端特征&＃xff0c;限制其访问频率&＃xff0c;客户端特征主要指 IP、UserAgent等。使用 IP 比 UserAgent 更可靠&＃xff0c;因为 IP 无法造假&＃xff0c;UserAgent 可随意伪造。

limit_req模块基于IP&＃xff1a;

http://nginx.org/en/docs/http/ngx_http_limit_req_module.html

tgngine&＃xff1a;

http://tengine.taobao.org/document_cn/http_limit_req_cn.html

本地接口限流

Semaphore

Java 并发库 的 Semaphore 可以很轻松完成信号量控制&＃xff0c;Semaphore 可以控制某个资源可被同时访问的个数&＃xff0c;通过 acquire() 获取一个许可&＃xff0c;如果没有就等待&＃xff0c;而 release() 释放一个许可。

假如我们对外提供一个服务接口&＃xff0c;允许最大并发数为40&＃xff0c;我们可以这样&＃xff1a;

private final Semaphore permit &＃61; new Semaphore(40, true);
public void process()
    try
        permit.acquire();
        //TODO 处理业务逻辑
     catch (InterruptedException e) 
        e.printStackTrace();
     finally 
        permit.release();
    


具体的 Semaphore 实现参考源码。

分布式接口限流

使用消息队列

不管是用MQ中间件&＃xff0c;或是Redis的List实现的消息队列&＃xff0c;都可以作为一个 缓冲队列 来使用。思想就是基于漏斗算法。

当对于一个接口请求达到一定阈值时&＃xff0c;就可以启用消息队列来进行接口数据的缓冲&＃xff0c;并根据服务的吞吐量来消费数据。

服务降级

在接口做好风控的前提下&＃xff0c;发现了接口请求的并发量迅速上升&＃xff0c;我们可以启用兜底方案&＃xff0c;进行服务降级。

一般服务降级应该用来对一些 不重要 或 不紧急 的服务或任务进行服务的 延迟使用 或 暂停使用。

降级方案

停止边缘业务

比如淘宝双11前&＃xff0c;就不可以查询三个月前的订单&＃xff0c;对边缘业务进行降级&＃xff0c;保证核心业务的高可用。

拒绝请求

在接口请求并发量大于阈值&＃xff0c;或是接口出现大量失败请求等等突发情况&＃xff0c;可以拒绝一些访问请求。

拒绝策略

• 随机拒绝&＃xff1a;随机拒绝超过阈值的请求 。

• 拒绝旧请求&＃xff1a;按照请求的时间&＃xff0c;优先拒绝更早收到的请求。

• 拒绝非核心请求&＃xff1a;根据系统业务设置核心请求清单&＃xff0c;将非核心清单内的请求拒绝掉。

恢复方案

在实现服务降级之后&＃xff0c;对于突增流量我们可以继续注册多个消费者服务来应对并发量&＃xff0c;之后我们再对一些服务器进行慢加载。

降级具体实现参考其他文章。

数据缓存

在接口做好风控的前提下&＃xff0c;发现了接口请求的并发量迅速上升&＃xff0c;我们可以分以下几个操作执行&＃xff1a;

• 对访问请求使用分布式锁进行阻塞。

• 在这个短时间中&＃xff0c;我们可以将对应操作行的热点数据&＃xff0c;缓存在缓存中间件中。

• 放行请求后&＃xff0c;让所有请求优先操作缓存数据。

• 再将操作的结果通过消息队列发送给消费接口慢慢消费。

缓存问题

假设我们操作的是一个库存接口&＃xff0c;此时数据库中只有100个库存。

那假如此时我们将一条数据放入缓存中&＃xff0c;如果所有的请求都来访问这个缓存&＃xff0c;那它还是被打挂&＃xff0c;我们该怎么操作&＃xff1f;

读写分离

第一种想法&＃xff0c;读写分离。

使用Redis的哨兵集群模式来进行主从复制的读写分离操作。读的操作肯定大于写操作&＃xff0c;等库存被消费到0时&＃xff0c;读操作直接快速失败。

负载均衡

第二种想法&＃xff0c;负载均衡。

在缓存数据后&＃xff0c;如果所有请求都来缓存中操作这个库存&＃xff0c;不管是加悲观锁还是乐观锁&＃xff0c;并发率都很低&＃xff0c;此时我们可以对这个库存进行拆分。

我们可以参照 ConcurrentHashMap 中的 counterCells 变量的设计思想&＃xff0c;将100个库存拆分到10个缓存服务中&＃xff0c;每个缓存服务有10个缓存&＃xff0c;然后我们再对请求进行负载均衡到各个缓存服务上。

但是这种方式会有问题&＃xff0c;如果大部分用户被hash到同一个缓存上&＃xff0c;导致其他缓存没有被消费&＃xff0c;却返回没有库存&＃xff0c;这是不合理的。

page cache

第三种想法&＃xff0c;page cache。

大部分软件架构其实都用到了这种方法&＃xff0c;比如linux内核的硬盘写入、mysql的刷盘等等&＃xff0c;即将短时间内的写操作聚合结果写入&＃xff0c;所有的写操作在缓存内完成。

来源&＃xff1a;blog.csdn.net/weixin_44414492/article/details/123027974

推荐

Java面试题宝典

技术内卷群&＃xff0c;一起来学习&＃xff01;&＃xff01;

PS&＃xff1a;因为公众号平台更改了推送规则&＃xff0c;如果不想错过内容&＃xff0c;记得读完点一下“在看”&＃xff0c;加个“星标”&＃xff0c;这样每次新文章推送才会第一时间出现在你的订阅列表里。点“在看”支持我们吧&＃xff01;